<p><code>MultiViews</code> is a per-directory option, meaning it
can be set with an <code class="directive"><a href="./mod/core.html#options">Options</a></code>
directive within a <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code>, <code class="directive"><a href="./mod/core.html#location"><Location></a></code> or <code class="directive"><a href="./mod/core.html#files"><Files></a></code> section in
<code>httpd.conf</code>, or (if <code class="directive"><a href="./mod/core.html#allowoverride">AllowOverride</a></code> is properly set) in
<code>.htaccess</code> files. Note that <code>Options All</code>
does not set <code>MultiViews</code>; you have to ask for it by
name.</p>
<p>The effect of <code>MultiViews</code> is as follows: if the
server receives a request for <code>/some/dir/foo</code>, if
<code>/some/dir</code> has <code>MultiViews</code> enabled, and
<code>/some/dir/foo</code> does <em>not</em> exist, then the
server reads the directory looking for files named foo.*, and
effectively fakes up a type map which names all those files,
assigning them the same media types and content-encodings it
would have if the client had asked for one of them by name. It
then chooses the best match to the client's requirements.</p>
<p><code>MultiViews</code> may also apply to searches for the file
named by the <code class="directive"><a href="./mod/mod_dir.html#directoryindex">DirectoryIndex</a></code> directive, if the
server is trying to index a directory. If the configuration files
<p>The server will also attempt to match language-subsets when no
other match can be found. For example, if a client requests
documents with the language <code>en-GB</code> for British
English, the server is not normally allowed by the HTTP/1.1
standard to match that against a document that is marked as simply
<code>en</code>. (Note that it is almost surely a configuration
error to include <code>en-GB</code> and not <code>en</code> in the
<code>Accept-Language</code> header, since it is very unlikely
that a reader understands British English, but doesn't understand
English in general. Unfortunately, many current clients have
default configurations that resemble this.) However, if no other
language match is possible and the server is about to return a "No
Acceptable Variants" error or fallback to the <code class="directive"><a href="./mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>, the server
will ignore the subset specification and match <code>en-GB</code>
against <code>en</code> documents. Implicitly, Apache will add
the parent language to the client's acceptable language list with
a very low quality value. But note that if the client requests
"en-GB; q=0.9, fr; q=0.8", and the server has documents
designated "en" and "fr", then the "fr" document will be returned.
This is necessary to maintain compliance with the HTTP/1.1
specification and to work effectively with properly configured
clients.</p>
<p>In order to support advanced techniques (such as cookies or
special URL-paths) to determine the user's preferred language,
since Apache 2.0.47 <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> recognizes
the <a href="env.html">environment variable</a>
<code>prefer-language</code>. If it exists and contains an
appropriate language tag, <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> will
try to select a matching variant. If there's no such variant,
<h2><a name="caching" id="caching">Note on Caching</a></h2>
<p>When a cache stores a representation, it associates it with
the request URL. The next time that URL is requested, the cache
can use the stored representation. But, if the resource is
negotiable at the server, this might result in only the first
requested variant being cached and subsequent cache hits might
return the wrong response. To prevent this, Apache normally
marks all responses that are returned after content negotiation
as non-cacheable by HTTP/1.0 clients. Apache also supports the
HTTP/1.1 protocol features to allow caching of negotiated
responses.</p>
<p>For requests which come from a HTTP/1.0 compliant client
(either a browser or a cache), the directive <code class="directive"><a href="./mod/mod_negotiation.html#cachenegotiateddocs">CacheNegotiatedDocs</a></code> can be
used to allow caching of responses which were subject to
negotiation. This directive can be given in the server config or
virtual host, and takes no arguments. It has no effect on requests
from HTTP/1.1 clients.</p>
<p>For HTTP/1.1 clients, Apache sends a <code>Vary</code> HTTP
response header to indicate the negotiation dimensions for the
response. Caches can use this information to determine whether a
subsequent request can be served from the local copy. To
encourage a cache to use the local copy regardless of the
negotiation dimensions, set the <code>force-no-vary</code> <a href="env.html#special">environment variable</a>.</p>
<p>For more information about content negotiation, see Alan
J. Flavell's <a href="http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html">Language
Negotiation Notes</a>. But note that this document may not be
updated to include changes in Apache 2.0.</p>
</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="./en/content-negotiation.html" title="English"> en </a> |
<a href="./ja/content-negotiation.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="./ko/content-negotiation.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p>
</div><div id="footer">
<p class="apache">Copyright 1995-2006 The Apache Software Foundation or its licensors, as applicable.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
